home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_1199 / 1030 < prev    next >
Internet Message Format  |  1994-08-27  |  3KB
  1. From: "Kevin O'Donovan" <abaddon@nasoftwr.demon.co.uk>
  2. Subject: Re: GEM apps, in general
  3. Date: Tue, 26 Jul 1994 11:47:26 +0100 (BST)
  4. In-Reply-To: <Pine.3.87.9407251347.D1140-0100000@grad> from "Timothy Miller" at Jul 25, 94 01:44:47 pm
  5. Precedence: bulk
  6.  
  7. > I can see what you're saying.  A duplicate screen would be rather memory 
  8. > expensive.  Nevertheless, what I did was still noticably faster... PLUS 
  9. > it kept track of the contents of the window for when I had to redraw a 
  10. > section.
  11. > 
  12. It may well be a lot faster, but its hideously expensive and inefficient.
  13. The main window of my first real gem application was a scrolling CLI window,
  14. and I initially considered doing redraws by maintaining a blittable copy of
  15. the screen. I soon realised I was just being lazy and did it properly though
  16. - I now save the objects on the screen (ie characters and their display
  17. attributes) instead, which has the advantage of taking less memory, of
  18. not having variable memory requirements for different colour depths, and of
  19. not being appreciably slower (apparently Ofir thought I was still blitting
  20. the screen for a while). It also gives me things like scrollback and cut and
  21. paste for free.
  22.  
  23.  
  24. > Bringing up one's toolkit is just fine.  It's the 'mine is better than 
  25. > yours' arguement that is the problem,
  26.  
  27. Indeed, I've been very reluctant to mention anything about what I'm doing
  28. because I want to avoid such childishness.
  29.  
  30. > You CANNOT leave everything up to the user!  If you did, the 
  31. > configuration woule be hell with countless options that must users 
  32. > wouldn't understand,
  33.  
  34. I've answered this earlier, but just to expand on it, configuration needn't
  35. be complex at all. Under X configuration of this nature is done in one of
  36. two places, the window manager's startup file or the user's .Xdefaults file.
  37. If these files are empty (a default for a naive user) then everything works
  38. fine (normally minimal files are provided by the systems administrator though).
  39. If the user wants to configure something then he just has to add a line to
  40. one of these files.
  41.  
  42. > and the executables would be HUGE with libraries 
  43. > with code for every conceivable option.
  44. Not really, there aren't that many such things to set really, as long as we
  45. are talking about window manager type functions and not application specific
  46. ones, Since this is a gem discussion list then I assume that's what we are
  47. talking about. However it does lead us nicely onto the subject of shared
  48. (dynamically linked) libraries...
  49.  
  50. > Plus, the library developer 
  51. > can't think of EVERYTHING.
  52. >
  53. He doesn't have to, others have done it for him. Check out guis on more
  54. mature platforms for inspiration then apply that to gem.
  55.  
  56. Kev
  57. -- 
  58. Kevin O'Donovan
  59. abaddon@nasoftwr.demon.co.uk
  60. kebab@cix.compulink.co.uk
  61.  
  62. Red meat isn't bad for you. Fuzzy blue-green meat is bad for you.
  63.  
  64.